System and method for modifying firmware used to initialize a computing device

ABSTRACT

A system and method for patching a boot sequence in a read-only memory. Patch instances are provided in an addressable memory. The patch instances are initially empty. The read-only memory includes a process that dynamically vectors to identified locations in a set of addressable memory locations in the addressable memory. Thereafter, the process returns to the next subsequent instruction following the patch instance. As corrections are required, the one or more patch instances are populated with one or more respective patches. The boot sequence is modified by inserting one or more patch indicators located where patches might need to be applied after a system-on-chip (SoC) is embodied in firmware. The patches, when defined, are populated with at least an encoded instruction type and an address. Accordingly, a patch is enabled in no more than three words.

RELATED APPLICATION

The present application claims priority to and the benefit of the filingdate of U.S. Provisional Application No. 61/973,203, entitled “Systemand Method for Modifying Firmware Used to Initialize a Computing Device”(Attorney Docket No. 141456P1) filed on Mar. 31, 2014, the entirety ofwhich is incorporated into this document by reference.

DESCRIPTION OF THE RELATED ART

Computing devices are ubiquitous. Some computing devices are portablesuch as mobile phones, tablets, and laptop computers. As thefunctionality of such portable computing devices increases, thecomputing or processing power required and generally the data storagecapacity to support such functionality also increases. In addition tothe primary function of these devices, many include elements thatsupport peripheral functions. For example, a cellular telephone mayinclude the primary function of enabling and supporting cellulartelephone calls and the peripheral functions of a still camera, a videocamera, global positioning system (GPS) navigation, web browsing,sending and receiving emails, sending and receiving text messages,push-to-talk capabilities, etc. Many of these portable devices include asystem-on-chip (SoC) to enable one or more primary and peripheralfunctions on the specific device.

A SoC generally comprises a processor embedded in an integrated circuitor chip which is coupled to a local bus. The SoC will generally includehardware components and other processors. The SoC, like larger computingdevices such as desktop and server computers relies on a boot sequenceor a boot code upon powering up. The boot sequence is the initial set ofoperations that the SoC performs when power is first applied to the SoC.The boot code enables a (i.e., bootstrapping) process that initializesthe SoC.

The boot code is typically stored in a read-only memory (ROM) for quickaccess, low complexity, spatial efficiency, low cost, and securityreasons. The ROM, otherwise known as a masked or boot ROM, has its codehardwired and thus cannot be reprogrammed later. This allows greatersecurity against reverse engineering of proprietary code and againstcryptographic attacks.

In a typical SoC design process, the boot ROM is defined well beforeother portions of the SoC have been completed. Complexity in the circuitarchitectures, feature sets, next generation market trends, performanceimprovements, identified security vulnerabilities and pre-siliconverification limitations have led to conventional boot ROM designs withlimited adaptability to enable changes post tape out of the SoC. Inthese conventional designs the boot ROM firmware is backed up with onetime programmable fuses that can enable instructions or statements anddata to be replaced during runtime execution.

FIG. 1 includes a schematic diagram illustrating how patches work in anexample conventional boot processor 10 of a computing device. Asillustrated, the boot processor 10 includes a boot ROM 12 including bootcode or code 20, a secured controller 14, one time programmable fuses 16and multiplexer logic 18. The secured controller 14 includes a patchregion 15, which includes a fixed number of addresses associated withrespective data fields. In the example embodiment the patch region 15includes 48 such addresses. The secured controller 14 also includes amemory 17. Prior to patching, the patch region 15 is empty and theone-time programmable fuses 16 are all intact. When a patch or change isrequired, one or more of the one-time programmable fuses are modified togenerate an open circuit condition. In addition, one or more of theaddresses and corresponding data fields are modified to include addressand data information. The open circuit condition directs the securedcontroller 14 to insert a patched address and the corresponding data inplace of the original boot ROM data. The multiplexer logic 18controllably forwards boot ROM data or patched data as desired to aprocessor (not shown) coupled to the boot processor 10.

For instruction patching it is often the case that the patch ormodification cannot be made in place. That is, a branch out instructionis required to use previously non-used memory to add the replacement ornew instructions. Thereafter, a branch back instruction is required toreturn to the original boot code. FIG. 2 includes a schematic diagramthat illustrates how patches are enabled in the conventional bootprocessor 10 of FIG. 1. Code 20 includes a sequence of instructions orstatements. The code 20 is defined by an address 22 and a statement orinstruction 24. Code addresses begin with 0x00000000 and end with thelast instruction or statement in the code 20. An original and unmodifiedcode 20 includes instructions or statements A through XX. A branch outinstruction or patch 30 is inserted between Statement C and Statement D.Patch addresses 32 begin with 0x10000000 and end with the lastinstruction or statement required to complete the patch 30. Each patchaddress 32 is associated with a corresponding statement or instruction34. As shown in FIG. 2, a total of five addresses are consumed whenimplementing the patch 30. A first address is consumed to insert thejump or branch instruction in the code 20. Two additional addresses areconsumed with the new instructions in the patch 30. For purposes ofillustration the OUT instructions are described as using one addresswhen in fact an OUT instruction consumes more than one address. Anadditional address is used to replace or restore Statement D, which wasoverwritten with the jump or branch instruction. A fifth address is usedto jump back to the next subsequent statement or instruction in the code20. Thus, five addresses are consumed to insert two new instructions inthe boot code 20.

Despite this flexibility the total die area cost and additionalcircuitry needed to multiplex address and data forces the one-timeprogrammable fuses 16 to be available in a limited quantity.Furthermore, the limited number of one time programmable fuses 16available must be shared with other one time programmable fuse 16 needsin the SoC.

In addition to the difficulties involved in repairing bugs in the ROMcode 20, it is also complicated to add new features to the ROM code 20.Such additional features may be determined by a system designer to bedesirable after the ROM has already been programmed and fabricatedwithin the SoC.

Thus, there is a need for improved mechanisms for securely modifying aboot sequence or other code hardwired in a read-only memory.

SUMMARY OF THE DISCLOSURE

Example embodiments of systems and methods are disclosed that enable apatch to be applied to a boot sequence or other sequence of instructionsstored in a read-only memory (ROM). An original boot sequence ismodified by inserting a patch indicator at a location in the bootsequence where a patch is likely to be desired after the SoC is embodiedin firmware. Any number of patch indicators may be inserted in theoriginal boot sequence to create a modified boot sequence. A patchinstance is initially empty and stored in a programmable memoryaccessible to a controller that loads instructions and data in aprocessor. The ROM includes patch processing logic that when executed bya processor dynamically vectors to the patch instance identified by thepatch indicator and thereafter returns to the next subsequentinstruction in the boot sequence. As patches are desired, an instructiontype is encoded in a first word and a patch address is provided in asecond word of the patch. For some instruction types a third word ispopulated with data.

An example embodiment of an improved system for patching a sequence ofinstructions stored in a read-only memory (ROM) includes a programmableread-only memory or PROM, the ROM, a random-access memory (RAM), acontroller and a processor. The PROM provides a set of addressablememory locations. The ROM has stored therein a sequence of instructionsand patch processing logic arranged to dynamically vector to identified(i.e., addressable) locations in the set of addressable memory locationsin the PROM and return to the sequence of instructions in the ROM. TheRAM is coupled to the PROM and ROM via a bus. The controller loads thesequence of instructions and patch processing logic from the ROM to theRAM. The processor is coupled to the RAM via the bus and executes thesequence of instructions. When a patch indicator is encountered in thesequence of instructions, the processor executes the patch processinglogic.

An example embodiment of a method for modifying a sequence ofinstructions in a read-only memory includes the steps of providing a setof addressable memory locations coupled to a processor, providing a setof one time programmable fuses coupled to the processor, providing asequence of instructions in a read-only memory coupled to the processorand enabling a patch process in the read-only memory that dynamicallyvectors to identified locations in the set of addressable memorylocations and returns to the sequence of instructions in the read-onlymemory, wherein when it is desired to modify the sequence ofinstructions, information in the set of one time programmable fusesdirects the processor to execute at least one instruction from a patch.

An example embodiment of a non-transitory processor-readable mediumhaving stored thereon processor instructions that when executed directthe processor to perform functions, includes logic that when executed bythe processor directs the processor to perform the steps of identifyingwhen a patch indicator is present in a sequence of instructions,determining when a patch instance is available at an address associatedwith the patch indicator, such that when a patch instance is notavailable, the processor loads and executes a next subsequentinstruction from the sequence of instructions. Otherwise, when a patchinstance is available, the processor performs the steps of determining apatch type from information stored at the address associated with thepatch indicator and executing at least one instruction from the patchinstance.

Another example embodiment of an improved system for patching a sequenceof instructions includes a means for providing a set of addressablememory locations, having stored therein at least one patch instance, ameans for storing a sequence of instructions and patch processing logicthat when executed by a means for executing the sequence of instructionsdynamically vector to identified locations in the set of addressablememory locations and return to the sequence of instructions, a means fortemporarily storing the sequence of instructions and patch processinglogic, a means for loading the sequence of instructions and the patchprocessing logic from the means for storing to the means for temporarilystoring and a means for executing the sequence of instructions from themeans for temporarily storing, wherein when a patch indicator isencountered in the sequence of instructions, the means for executingexecutes the patch processing logic.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings, like reference numerals refer to like parts throughoutthe various views unless otherwise indicated. For reference numeralswith letter character designations such as “102A” or “102B”, the lettercharacter designations may differentiate two like parts or elementspresent in the same figure. Letter character designations for referencenumerals may be omitted when it is intended that a reference numeral toencompass all parts having the same reference numeral in all figures.

FIG. 1 is a schematic diagram illustrating how patches work in aconventional boot processor.

FIG. 2 is a schematic diagram illustrating how patches are enabled inthe conventional boot processor of FIG. 1.

FIG. 3 is a schematic diagram illustrating an example embodiment of acomputing device that includes an improved ROM patch process.

FIG. 4 is a schematic diagram illustrating an example embodiment of asystem that enables an improved ROM patch process.

FIG. 5 is a schematic diagram illustrating an embodiment of an exampleboot ROM code sequence with two patch instances.

FIG. 6 is a schematic diagram illustrating an embodiment of the exampleboot ROM code sequence of FIG. 5 before patches are defined.

FIG. 7 is a schematic diagram illustrating example embodiments of twodefined patches in the example boot ROM code sequence of FIG. 6.

FIG. 8 is a flow diagram illustrating an embodiment of the improved ROMpatch process as enabled by the patch logic of FIG. 4.

FIGS. 9A & 9B illustrate example embodiments of a write instruction anda write with mask, respectively.

FIGS. 10A & 10B illustrate example embodiments of a wait until a bit isclear instruction and a wait until a bit is set instruction,respectively.

FIG. 11 is a schematic diagram illustrating an example embodiment of aboot sequence and a set of hypothetical patches.

FIG. 12 is a flow diagram of an example embodiment of a method formodifying a sequence of instructions in a read-only memory.

FIG. 13 is a schematic diagram illustrating an embodiment of acomputer-readable medium.

DETAILED DESCRIPTION

The word “exemplary” is used herein to mean “serving as an example,instance, or illustration.” Any aspect described herein as “exemplary”is not necessarily to be construed as preferred or advantageous overother aspects.

In this description, the term “application” may also include fileshaving executable content, such as: object code, scripts, byte code,markup language files, and patches. In addition, an “application”referred to herein, may also include files that are not executable innature, such as documents that may need to be opened or other data filesthat need to be accessed.

The term “content” may also include files having executable content,such as: object code, scripts, byte code, markup language files, andpatches. In addition, “content” referred to herein, may also includefiles that are not executable in nature, such as documents that may needto be opened or other data files or data values that need to beaccessed.

As used in this description, the terms “component,” “module,” “system,”and the like are intended to refer to a computer-related entity, eitherhardware, firmware, a combination of hardware and software, software, orsoftware in execution. For example, a component may be, but is notlimited to being, a process running on a processor, a processor, anobject, an executable, a thread of execution, a program, and/or acomputer. By way of illustration, both an application running on acomputing device and the computing device may be a component. One ormore components may reside within a process and/or thread of execution,and a component may be localized on one computer and/or distributedbetween two or more computers. In addition, these components may executefrom various computer-readable media having various data structuresstored thereon. The components may communicate by way of local and/orremote processes such as in accordance with a signal having one or moredata packets (e.g., data from one component interacting with anothercomponent in a local system, distributed system, and/or across a networksuch as the Internet with other systems by way of the signal).

In this description, the term “portable computing device” (“PCD”) isused to describe any device operating on a limited capacity rechargeablepower source, such as a battery and/or capacitor. Although PCDs withrechargeable power sources have been in use for decades, technologicaladvances in rechargeable batteries coupled with the advent of thirdgeneration (“3G”) and fourth generation (“4G”) wireless technology haveenabled numerous PCDs with multiple capabilities. Therefore, a PCD maybe a cellular telephone, a satellite telephone, a pager, a PDA, asmartphone, a navigation device, a smartbook or reader, a media player,a combination of the aforementioned devices, a laptop or tablet computerwith a wireless connection, among others.

A system and method for patching a boot sequence in a hardwired or bootROM are disclosed. An original or unmodified boot sequence is stored inthe ROM. The original or unmodified boot sequence is pre-loaded with oneor more patch instances. The patch instances are strategically locatedwhere patches might need to be applied after a system-on-chip (SoC) isembodied in firmware. These patch instances are initially empty. Thepatch instances are stored in a programmable memory accessible to acontroller coupled to a random access memory (RAM) and a processor. TheROM includes a process that dynamically vectors to identified locationsin a set of addressable memory locations in the programmable memory.Thereafter, the process returns to the next subsequent instructionfollowing the patch instance. As corrections are desired, the one ormore patch instances arc populated with respective patches. The patchesinclude an instruction type, an address, and a return indicator. In somevariations, the patches also include a data field. Accordingly, a patchis enabled in no more than 4 words.

The present system and method for modifying firmware used to boot acomputing device define a set of common instructions used in boot ROMpatches or modifications. By pre-defining common instructions and usingthe same with an embedded or stored process for vectoring or jumping toaddressable memory locations in a PROM or other available memory andreturning to the boot ROM upon completion of the patch, the presentsystem and methods optimize the total use of the limited one-timeprogrammable fuses while enabling boot ROM modifications post silicontape out.

Although described with particular reference to operation within a PCD,the described systems and methods are applicable to any computing systemwith a boot sequence in a ROM where it may be useful to patch or modifythe original boot sequence to avoid the costs associated with an entirereplacement of the ROM. Stated another way, the systems and methodsdisclosed herein are applicable to desktop computers, server computersor any electronic device with an embedded boot sequence stored in a ROM.

Reference is now directed to the illustrated examples. Referringinitially to FIG. 3, an exemplary, non-limiting aspect of a PCD 100 isshown. The PCD 100 includes an on-chip system or SoC 120 that includes amulticore CPU 210. The multicore CPU 210 includes a zero^(th) core 215,a 1^(st) or first core 216, and an N^(th) core 217. Each of the N coresare independent from each other and arranged to process instructionssuch as add, move data, branch, etc. The multicore CPU 210 is coupled toa general-purpose input output (GPIO) bus 211, and is arranged toinclude at least one programmable memory or PROM 212, and a controller214. Each of the N cores operates in conjunction with signalscommunicated on the GPIO bus 211 or from an eFuse element 192, as wellas instructions received from the ROM 190, the system memory 230 orprograms or files 143 stored in a USB enabled data store 142.

The GPIO bus 211 may be configured to send signals from the CPU 210 toany peripheral devices external to the on-chip system 120 or converselyto receive signals from any devices external to the on-ship system 120.Such peripheral devices may include one or more of those illustrated inFIG. 1 or in some cases devices not shown in FIG. 1. As will beexplained, the GPIO bus 211 may be used to direct the SoC 120 to enterand operate in a desired mode of operation where executable processorinstructions are downloaded from a storage device coupled to the SoC120. In addition, the GPIO bus 211 may be used to adjust or modify datastored in the PROM 212 and/or to configure the eFuse element 192.

In the illustrated arrangement the PROM 212 is an internal (integrated)memory element capable of storing data that may be retrieved by any ofthe N cores at a desired time as determined by the respective cores. ThePROM 212 is configured to provide a set of storage locations that aredesignated for respective patches or sets of instructions.

The controller 214 is coupled to each of the N cores and is configuredto access and provide instructions and data from any of the variousstorage devices (both internal and external to the multicore CPU 210) ina controlled manner to the N cores or the other various processorswithin the SoC 120. In the present system, the controller 214 isconfigured to operate as a tightly-coupled memory for the retrieval ofprocessor instructions, status information and vector or branch logic.

The read-only memory (ROM) 190 is an integrated circuit that includesthe code or codes that are executed by the CPU 210 during an initialpower-on or upon a watchdog reset condition. Preferably, the ROM isenabled in firmware.

As illustrated in FIG. 3, a display controller 128 and a touch screencontroller 130 are coupled to the multicore CPU 210. In turn,display/touchscreen 132, external to the on-chip system 120, is coupledto the display controller 128 and the touch screen controller 130.

FIG. 3 further indicates that a video encoder 134, e.g., a phasealternating line (PAL) encoder, a sequential couleur a memoire (SECAM)encoder, or a national television system(s) committee (NTSC) encoder, iscoupled to the multicore CPU 210. Further, a video amplifier 136 iscoupled to the video encoder 134 and the display/touchscreen 132. Also,a video port 138 is coupled to the video amplifier 136. As depicted inFIG. 3, a universal serial bus (USB) controller 140 is coupled to themulticore CPU 210. Also, a USB storage device 142 is coupled to the USBcontroller 140. A file 143, stored in the USB storage device 142, isavailable to be transferred to the system memory 230. In addition, asubscriber identity module (SIM) card interface 146 may also be coupledto the multicore CPU 210 with the connection 219 between the multicoreCPU 210 and the system memory 230 consisting of two or more physicalchannels or paths for transferring data between these elements of theSoC 120. Further, as shown in FIG. 3, a digital camera 148 may becoupled to the multicorc CPU 210. In an exemplary aspect, the digitalcamera 148 is a charge-coupled device (CCD) camera or a complementarymetal-oxide semiconductor (CMOS) camera.

As illustrated in FIG. 3, a stereo audio CODEC 150 may be coupled to themulticore CPU 210. Moreover, an audio amplifier 152 may be coupled tothe stereo audio CODEC 150. In an exemplary aspect, a first stereospeaker 154 and a second stereo speaker 156 are coupled to the audioamplifier 152. FIG. 3 shows that a microphone amplifier 158 may be alsocoupled to the stereo audio CODEC 150. Additionally, a microphone 116may be coupled to the microphone amplifier 158. In a particular aspect,a frequency modulation (FM) radio tuner 162 may be coupled to the stereoaudio CODEC 150. Also, a FM antenna 164 is coupled to the FM radio tuner162. Further, a stereo port 166 may be coupled to the stereo audio CODEC150.

FIG. 3 also indicates that a radio frequency (RF) transceiver 168 iscoupled to the multicore CPU 210. An RF switch 170 may be coupled to theRF transceiver 168 and an RF antenna 172. As shown in FIG. 3, a keypad174 is coupled to the multicore CPU 210. Also, a mono headset with amicrophone 176 may be coupled to the multicore CPU 210. Further, avibrator device 178 may be coupled to the multicore CPU 210. FIG. 3further shows that a power supply 180 may be coupled to the on-chipsystem 120 via the USB controller 140. In a particular aspect, the powersupply 180 is a direct current (DC) power supply that provides power tothe various components of the PCD 100 that require power. Further, in aparticular aspect, the power supply 180 is a rechargeable DC battery ora DC power supply that is derived from an alternating current (AC) to DCtransformer that is connected to an AC power source.

FIG. 3 further indicates that the PCD 100 may also include a networkcard 188 that may be used to access a data network, e.g., a local areanetwork, a personal area network, or any other network. The network card188 may be a Bluetooth network card, a WiFi network card, a personalarea network (PAN) card, or any other network card well known in theart. Further, the network card 188 may be incorporated in an integratedcircuit. That is, the network card 188 may be a full solution in a chip,and may not be a separate network card 188.

As depicted in FIG. 3, the display/touchscreen 132, the video port 138,the USB port 142, the camera 148, the first stereo speaker 154, thesecond stereo speaker 156, the microphone 116, the FM antenna 164, thestereo port 166, the RF switch 170, the RF antenna 172, the keypad 174,the mono headset 176, the vibrator 178, and the power supply 180 areexternal to the on-chip system 120.

RF transceiver 168, which may include one or more modems, supports oneor more of global system for mobile communications (“GSM”), codedivision multiple access (“CDMA”), wideband code division multipleaccess (“W-CDMA”), time division synchronous code division multipleaccess (“TDSCDMA”), long term evolution (“LTE”), and variations of LTEsuch as, but not limited to, FDB/LTE and PDD/LTE wireless protocols.

In the illustrated embodiment, a single instance of a multi-core CPU 210is depicted. However, it should be understood that any number ofsimilarly configured multi-core CPUs can be included to support thevarious peripheral devices and functions associated with the PCD 100.Alternatively, a single processor or multiple processors each having asingle arithmetic logic unit or core could be deployed in a PCD 100 orother computing devices to support the various peripheral devices andfunctions associated with the PCD 100 as may be desired.

FIG. 4 is a schematic diagram illustrating an example embodiment of aSoC based system that enables an improved ROM patch process. The SoC 120includes the ROM 190, PROM 212, multicore processor 210, controller 214,eFuse element 192, and system memory 230 introduced in the PCD 100 ofFIG. 3. In the arrangement illustrated in FIG. 4, each of the processor210, the controller 214, the system memory 230, the ROM 190 and the PROM212 are coupled to a bus 402, which enables the transfer of data andinstructions to and from the multicore processor 210 and each of thestorage elements (i.e., the ROM 190, the PROM 212 and the system memory230. The eFuse element 192, which includes M separate fuses where M isan integer, is coupled to the controller via a connection 404. The Mseparate fuses are provided in a limited quantity and often must beshared with other mechanisms on the PCD 100. The M separate fuses in theeFuse element 192 provides a set of one time programmable fuses that arecoupled to the controller 214 and the multicore processor 210 via theconnection 404 and the bus 402. When the multicore processor 210 isexecuting the instructions in the modified boot code 500, the multicoreprocessor 210 retrieves an address by accessing the set of one timeprogrammable fuses to authenticate and define an addressable locationwhere a patch instance, such as one of the patch instance 610, patchinstance 611 or another patch instance 650 is stored.

In this embodiment the modified boot code 500 is provided in the ROM190. As briefly explained, a modified boot code 500 includes a sequenceof instructions and one or more patch indicators that when executed bythe multicore processor 210 initialize the PCD 100. The instructions mayinclude the transfer of critical elements of an operating system intovarious registers of the multicore processor 210 (not shown).Alternatively, an original boot code is stored on ROM 190, during themanufacturing of the SoC 120. An original boot code may or may notinclude the one or more patch indicators.

The patch instances, i.e. the instructions and data that together formthe patching commands, are preferably stored in PROM 212, where thepatch instances may include bug fixes, new features, new data, hardwareinput/output fixes or other alterations to the original boot code ormodified boot code 500 stored on ROM 190. When populated, for example,with instructions and data, the patch instances 610, 611, . . . , 650include patch data. The patch instances 610, 611 through patch instance650 may be stored in a number of formats and ways, such as storing pairsof addresses and instructions, meaning, that a requested patchingcommand is written as a new command with an attached address. Whenstored in the PROM 212 and/or the system memory 230, the patch instances610, 611, . . . , 650 are placed or located at an addressable locationsuch that the controller 214 and the processor 210 can repeatedly accessthe replacement content therein as desired. In this way, patch instances610, 611 through 650, in accordance with the patch process logic 800,can replace original commands or instructions in the original boot codeor the modified boot code 500. Each patch instance 610, 611 through 650may include any number of instructions or commands and is limited onlyby the addressable storage capacity of the PROM 212 and the addressablestorage capacity of the system memory 230. As described, the processor210 is a physical element or mechanism for executing the sequence ofinstructions from the system memory 230.

In an alternative embodiment, the PROM 212 is arranged external to theSoC 120. This enables the PROM 212 to be programmed at a different placethan the factory producing the SoC 120, thus allowing the SoC designerto manufacture the SoC 120 and then, later on, program the PROM 212,after the SoC 120 has been manufactured. For example, the PROM 212 maybe programmed after a new feature is requested or after a bug has beenfound in the original boot code stored in ROM 190. The PROM 212 may be aone-time programmable (OTP) device or integrated circuit element, anerasable programmable read-only memory (EPROM), an electrically erasableprogrammable read-only memory (EEPROM), an electrically alterableread-only memory (EAROM), or any other known programmable memory, whichcan be programmed once or a number of times. In some embodiments, theGPIO bus 211 may be used as a mechanism for altering the data or asource for providing data and addresses in one or more of the patchinstance 610, the patch instance 611 or the patch instance 650 amongother patch instances stored in the PROM 212. As described, the PROM 212is a physical mechanism or element for providing a set of addressablememory locations, having stored therein at least one patch instance.

The system memory 230 may be any volatile memory used for loading andunloading data during processing, such as a static random-access memory(SRAM). When the SoC 120 is powered, controller 214 transfers theoriginal (i.e., unmodified) boot code or the modified boot code 500 fromROM 190 into the system memory 230, over bus 402, where the boot codeawaits execution by processor 210. After the boot code is copied intothe system memory 230, the patch process logic 800 is transferred fromthe ROM 190 into corresponding addresses of the system memory 230. Asthe instructions are processed or executed by the processor 210, a patchindicator directs the processor to branch to the patch process logic800. If no patch has been identified, the patch instance identified bythe patch indicator will be empty and no patch is available. When thisis the case, the patch processing logic 800 directs the processor 210 toreturn to the next subsequent instruction in the modified boot code 500.Alternatively, when a patch is identified and the patch instanceidentified by the patch indicator is populated with one or moreinstructions, the instructions are executed until the patch instance isexhausted. Thereafter, the patch processing logic 800 directs theprocessor 210 to execute the next subsequent instruction in the modifiedboot code 500. Note that the patch instances can be transferredseparately or together to the system memory 230. Alternatively, one ormore patch instances 610, 611, . . . , 650 can be accessed by thecontroller 214 from the PROM 212 and read and copied into respectiveaddresses in system memory 230 replacing the corresponding commands fromthe modified boot code 500 loaded from ROM 190. Thus, when processor 210executes the modified boot code 500 from the system memory 230, itexecutes the patched or corrected code. In other embodiments, ROM 190,PROM 212, system memory 230, controller 214 and other parts of the SoC120 may not share the same bus, and may have different combinations ofinterconnecting buses.

As described, the system memory 230 is a physical element or mechanismfor temporarily storing the sequence of instructions and patchprocessing logic. The system memory 230 temporarily stores data andinstructions as the data and instructions are lost when power is removedfrom the SoC 120.

As described, the controller 214 is a physical element or mechanism forloading the sequence of instructions and the patch processing logic fromthe ROM 190 to the system memory 230.

In some embodiments, the ROM 190 includes authentication logic 405 thatenables an optional secure boot process. This secure boot process usesone or more mechanisms to authenticate the source of the processorinstructions being loaded from one of the sources available forcommunicating or transporting such instructions into the SoC 120. Asdescribed the ROM 190 is a physical element or mechanism for storing asequence of instructions such as the modified boot code 500, patchprocessing logic or patch process logic 800 and in some embodimentsauthentication logic 405.

FIG. 5 is a schematic diagram illustrating exemplary embodiments of aboot ROM code sequence 20 and a modified boot code 500 with two patchinstances inserted at strategic locations between statements orinstructions. Code 20 is depicted in pseudo-code as a series or set ofinstructions or statements 28. Design engineers know from experiencelocations in such code sequences where patches or corrections are likelyto be needed. Example locations are indicated in bold text in the firstor unpatched boot code 20. Accordingly, a number of desired patchindicators are inserted immediately before the identified statements orinstructions in the unmodified boot ROM code 20 to generate a modifiedboot ROM code 500. For example, a patch indicator 501, with anidentifier or index of 0, is inserted between statement B and statementC. By way of further example, a patch indicator 502, with an identifieror index of 1, is inserted between Statement D and statement E. Themodified boot code 500 includes a set or sequence of instructions orstatements 510 with at least one patch indicator 501, 502. The strategicor desired locations in the boot ROM code sequence shown in bold textdefine a place in the sequence of instructions where a required changeor correction is probable after the sequence of instructions is embodiedin firmware. That is, hardware changes, silicon characterization, orother issues that are discovered after the SoC 120 design is completedmay require changes in the in the boot ROM code sequence.

FIG. 6 is a schematic diagram illustrating an embodiment of the exampleboot ROM code or sequence 500 of FIG. 5 before patches are defined. Thatis, before a patch or modification is defined or required, the patchinstance 610, which can be associated with the patch indicator 501inserted between statement B and statement C, and the patch instance611, which can be associated with the patch indicator 502 insertedbetween statement D and statement E, are empty. The patch instances arestored at respective addressable memory location in the PROM 212.

FIG. 7 is a schematic diagram illustrating example embodiments of twodefined patches in the example boot ROM code sequence 500 of FIG. 6. Afirst patch 710 includes two instructions. A first instruction 712includes a type identifier or type code, an address and a datum orvalue. A second instruction 714 includes a type identifier or type code,an address and a datum or value. A return indicator 716 including allzero values follows the first patch 710. A second patch 711 includes asingle instruction 713. In the illustrated embodiment, each instructionis defined by an instruction type, an address and a data or value. Afterthe instructions, an empty word or word with all zero values indicatesto the ROM patch process that the processor should return to the nextsubsequent instruction or statement in the boot ROM code sequence 500.

FIG. 8 is a flow diagram illustrating an embodiment of the improved ROMpatch process as enabled by the patch process logic 800 introduced inFIG. 4. As described, the improved ROM patch process dynamically vectorsto addressable memory locations accessible to a processor, such as themulticore processor 210, over a bus. The improved ROM patch processhandles common categories of changes necessitated post-siliconcharacterization on an as needed basis. The common instructions includea write instruction, a write with mask instruction, a wait until a bitis clear instruction, and a wait until a bit is set instruction. Whenexecuted, the patch process logic 800 directs a processor to retrieve anaddress from a source other than the sequence of instructions, determinewhether patch data is available at the address. When patch data is notavailable at the address, the processor 210 is directed to return to anext subsequent instruction in the sequence of instructions. Otherwise,the processor 210 is directed to execute the instructions in the patchdata, and return to the next subsequent instruction in the sequence ofinstructions once the patch is exhausted. It should be understood thatthe present instruction architecture can be extended and/or modified asmay be desired to support additional instructions.

The patch process logic 800 embodies a method 801 that begins with block802 where an address is retrieved or identified. As described, a set ofone-time programmable fuses may be used to identify an address in a bootROM code sequence that should be overwritten or patched. In decisionblock 804, it is determined whether a patch is available at theidentified address. A patch is considered available when the patchinstance is populated with an instruction type, a patch address and forsome instructions a data field. A patch is considered unavailable whenthe identified address is empty or includes all zero values. Such anaddress location includes empty content. When this is the case, asindicated by the flow control arrow labeled “No,” exiting decision block804, the improved ROM patch process is arranged to return to the nextsubsequent instruction, as shown in block 806. Otherwise, when the patchis available (i.e., when there is non-zero bits at the locationidentified by the address, a patch type is determined or identified, asindicated in block 808. As further indicated in the flow diagram, whenthe patch type identified in block 808 indicates a simple write isdesired, the method 801 branches to the corresponding logic and executesthe same, as indicated in block 810, before returning to repeat thefunctions associated with blocks 804 through 808. When the patch typeidentified in block 808 indicates a write with mask instruction isdesired, the method 801 branches to the corresponding logic and executesthe write with mask instruction, as indicated in block 812, beforereturning to repeat the functions associated with blocks 804 through808. When the patch type identified in block 808 indicates a wait untilbit is clear instruction is desired, the method 801 branches to the waituntil a bit is clear logic and executes the wait until bit is clearinstruction, as indicated in block 814, before returning to repeat thefunctions associated with blocks 804 through 808. Similarly, when thepatch type identified in block 808 indicates a wait until bit is setinstruction is desired, the method 801 branches to the correspondinglogic and executes the wait until bit is set instruction, as indicatedin block 816, before returning to repeat the functions associated withblocks 804 through 808. Although four common instructions areillustrated and described, those skilled in the art can modify orotherwise adapt the instruction architecture described herein to enableadditional instructions as may be desired.

FIGS. 9A & 9B illustrate example embodiments of a write instruction 900and a write with mask instruction 950, respectively. As shown in FIG.9A, the write instruction 900, which may be represented in a pseudo-codestatement as “OUT(address, value);” is defined by a first word 910, asecond word 920 and a third word 930. Each of the three words includes Nbits where N is an integer. In the illustrated embodiment, the words are32 bits in length. The first 29 bits of the first word 910 are reservedor define a reserved region 912. The following three bits of the firstword 910 include a code that defines the instruction type in a typeregion 914. In the example embodiment, the write instruction isidentified by “000.” As further indicated in FIG. 9A, the address isdefined in the second word 920 and the data or value information isdefined in the third word 930.

The write instruction in the example embodiment may be identified orarranged using other codes of various lengths or positions. Furthermore,the sequence of the first, second and third words may be modified fromthe illustrated embodiment as may be desired. Moreover, the length ofthe words used to represent the example write instruction may be variedto apply in a system or systems that deploy addresses and data in otherthan 32 bits.

As shown in FIG. 9B, a write with mask instruction 950, is representedby a first word 960 including a reserved region 962, a mask region 964and a type region 966. The mask region 964 includes mask information.The type region 966 includes a code that identifies the instructiontype. The three words of the write with mask instruction 950 include Nbits where N is an integer. The write with mask instruction may berepresented in pseudocode by “New_value =IN(address); New_value&=mask;New_value|=value; OUT(address, New_value);” The first 24 bits of thefirst word 962 are in the reserved region 962. In the exampleembodiment, the write with mask instruction 950 is identified by thefollowing or last eight bits of the first word 960, with bits 25 through29 defining the mask and bits 30 through 32 defining the instructiontype with the code “001.” As further indicated in FIG. 9B, the addressis defined in the second word 970 and the data or value information isdefined in the third word 980.

The write with mask instruction in the example embodiment may beidentified or arranged using other codes of various lengths orpositions. For example, a set of mask bits or mask information may usemore or less than 5 bits and may be located anywhere over the range ofbits that are not used to encode the instruction type. Furthermore, thesequence of the first word 960, the second word 970 and third word 980may be modified from the illustrated embodiment as may be desired.Moreover, the length of the words used to represent the example writewith mask instruction 950 may be varied to apply in a system or systemsthat deploy addresses and data in other than 32 bits.

FIGS. 10A & 10B illustrate example embodiments of a wait until a bit isclear instruction 1000 and a wait until a bit is set instruction 1050,respectively. As shown in FIG. 10A, a wait until bit is clearinstruction 1000, is represented by a first word 1010 that includes areserved region 1012, a mask region 1014 and a type region 1016. Themask region 1014 includes mask information. The type region 1016includes a code that identifies the instruction type. The words of thewait until bit is clear instruction 1000 include N bits where N is aninteger. The wait until a bit is clear instruction 1000 may berepresented in pseudo-code by “While (IN(address, mask)!=0).” The first24 bits of the first word 1010 are reserved. In the example embodiment,the mask region 1014 is defined in bits 25 through 29 and the typeregion 1016 is located in bits 30 through 32 of the first word 1010. Inthe illustrated embodiment, the wait until bit is clear instruction 1000is defined by the code “010.” As further indicated in FIG. 10A, theaddress is defined in the second word 1020.

The wait until a bit is clear instruction 1000 in the example embodimentmay be identified or arranged using other codes of various lengths orpositions. For example, a set of mask bits or mask information may usemore or less than 5 bits and may be located anywhere over the range ofbits that are not used to encode the instruction type. Furthermore, thesequence of the first word 1010 and second word 1020 may be modifiedfrom the illustrated embodiment as may be desired. Moreover, the lengthof the words used to represent the example wait until a bit is clearinstruction 1000 may be varied to apply in a system or systems thatdeploy addresses and data in other than 32 bits.

A wait until bit is set instruction 1050 is illustrated in FIG. 10B. Thewait until bit is set instruction 1050 instruction includes a first word1060 that includes a reserved region 1062, a mask region 1064 and a typeregion 1066 and a second word 1070 that includes address information.Each of the first word 1060 and the second word 1070 includes N bitswhere N is an integer. The wait until a bit is set instruction 1050 isrepresented in pseudo-code by the expression “While (IN(address,mask)!=1).” The first 24 bits of the first word 1060 are in the reservedregion 1062. The mask region 1064 is located in bits 25 through 29 andthe type region 1066 is in bits 30 through 32. In the illustratedembodiment, the wait until bit is set instruction 1050 is defined by thecode “011.”

The wait until a bit is set instruction 1050 in the example embodimentmay be identified or arranged using other codes of various lengths orpositions. For example, a set of mask bits or mask information may usemore or less than 5 bits and may be located anywhere over the range ofbits that are not used to encode the instruction type. Furthermore, thesequence of the first word 1060 and second word 1070 may be modifiedfrom the illustrated embodiment as may be desired. Moreover, the lengthof the words used to represent the example wait until a bit is setinstruction 1050 may be varied to apply in a system or systems thatdeploy addresses and data in other than 32 bits.

It should be further understood that the instructions illustrated inFIGS. 9A, 9B, 10A, and 10B are presented by way of example only. Thus,the present system and methods are not limited to these instructions.Accordingly, these example instructions or any number of additionalinstructions, however encoded and arranged, may be generated anddeployed as may be desired.

FIG. 11 is a schematic diagram illustrating an example embodiment of apatched boot code sequence 1100. To illustrate the significance of thesavings in one-time programmable fuses enabled with the present systemand methods, four example patches are shown side-by-side with aconventional patch for the same instruction. For example, a patch 1110,identified in the patched boot code 1100 by patch indicator (0),includes a write instruction as indicated by the code 000. As definedabove, the write instruction is defined in three N bit words. The returnindicator, which includes all zeros is not part of the patch and doesnot change when a patch is defined and stored in the addressable memory.Thus, the improved instruction architecture and process enable a savingsof six fuse locations over the conventional patch implementation whichconsumes a total of nine fuses.

By way of further example, patch 1120, identified in the patched bootcode 1100 by patch indicator (1), includes a write with maskinstruction, as indicated by the mask bits and code 001. As definedabove, the write with mask instruction is defined in three N bit words.Thus, the improved instruction architecture and process enable a savingsof eight fuse locations over the conventional patch implementation,which consumes a total of eleven fuses.

Patch 1130, identified in the patched boot code 1100 by patch indicator(2), includes a wait until bit is clear instruction, as indicated by themask bits XXX and code 010. As defined above, the wait until bit isclear instruction is defined in two words. As illustrated, the improvedinstruction architecture and process enables a savings of eight fuseswhen compared to the conventional patch implementation, which consumes atotal of ten fuse locations.

Patch 1140, identified in the patched boot code 1100 by patch indicator(3), includes a wait until bit is set instruction, as indicated by maskbits XXXXX and the code 011 in bits 30-32 of the first word. As definedabove, the wait until bit is set instruction provides an address in thesecond word of the patch 1140. Thus, the improved instructionarchitecture and process enable a savings of eight fuse locations overthe conventional patch implementation, which consumes a total of tenfuses.

Each of the original boot code 20′, patched boot code 1100, conventionalpatches (as indicated in broken lines), and the improved patches orpatch instances (0)-(3) are presented by way of example only. Thepresent system and methods are not limited to these instructionsequences or patch instruction architectures. Those skilled in the artwill understand how to make and use an improved ROM including theabove-described patch process logic in any of a number of variationsconsistent with the claimed systems and methods.

FIG. 12 is a flow diagram of an example embodiment of a method 1200 formodifying (i.e., patching) a sequence of instructions in a ROM. Themethod begins with block 1202 where a patch indicator is inserted at adesired location in a sequence of instructions in a ROM. Block 1202 isillustrated in broken line to show that the insertion of a patchindicator in the sequence of instructions stored in a ROM can be made inan optional preliminary step. In block 1204, a set of addressable memorylocations are provided. As indicated above, the set of addressablememory locations are preferably enabled by a programmable ROM or PROM212. In conjunction with the optional preliminary step of inserting atleast one patch indicator at a desired location in the sequence ofinstructions in the read-only memory, at least one patch instance isstored in the set of addressable memory locations. Preferably, an indexor other identifier associates the patch indicator with a respectivepatch instance at an addressable memory location in the PROM 212. Beforea change is required to the sequence of instructions in the ROM 190, thepatch instances stored in the PROM 212 may include empty content. Inblock 1206, a set of one-time programmable fuses are provided. Theone-time programmable fuses may be “opened” by controlled application ofa high voltage signal, exposure to ultraviolet radiation, or othermechanisms. Thus, the one-time programmable fuses may be controllablymodified to reflect one or more addresses in the set of addressablememory locations. In block 1208, a sequence of instructions is providedin a ROM. In block 1210, a patch process is enabled in the ROM. Thepatch process dynamically vectors or jumps to the set of addressablememory locations and upon encountering a return indicator, returns tothe sequence of instructions in the ROM. As shown in block 1212, when itis desired to patch or modify the sequence of instructions in thedesired location in the ROM, information communicated by the one-timeprogrammable fuses directs a processor or controller to load and executeinstructions stored in the set of addressable memory locations,inserting at least one patch indicator at a desired location in thesequence of instructions in the read-only memory, wherein at least onepatch instance in the set of addressable memory locations as defined bythe at least one patch indicator includes empty content before acorrection to the sequence of instructions in the read-only memory isidentified

While the ROM 190 and its patch process logic 800 are preferably enabledin a circuit, the logic represented therein may be stored on anon-transitory computer readable medium and available for transport orfor making copies as may be desired. FIG. 13 includes a schematicrepresentation of a computer-readable medium 1300 that includes patchprocess logic 800 stored therein. As indicated in FIG. 13, the patchprocess logic 800 includes indicator logic 1310, instance logic 1320,type logic 1330 and return logic 1340. Indicator logic 1310 directs aprocessor to identify when a patch indicator is present in a sequence ofinstructions or statements. Instance logic 1320 directs a processor toidentify when an addressable memory location includes non-zero bits(i.e., non-empty content). Type logic 1330 directs a processor toidentify an instruction by decoding information in a type regionembedded in the patch instance. Return logic 1340 directs a processorupon encountering a series of zero bits to return to the next subsequentinstruction in the sequence of instructions or statements.

In addition to the above described logic, other data and/or processorinstructions may be stored on a computer-readable medium for transportvia a download mode of operation onto the SoC 120 for storage in thePROM 212. When stored a computer-readable medium, these otherinstructions and corresponding data are also available for transport orfor making copies as may be desired.

As described, the one or more non-transitory computer-readable medium ormedia may have stored thereon processor instructions that when executeddirect the processor 210 to configure a computing device responsive toone of a download or programming mode of operation that receivesprocessor executable logic and/or data from a source other than thecomputing device.

As further described processor instructions responsive to one or moreinput signals received from a GPIO bus 211 or a programmable eFuseelement 192 may be used to identify a download mode, an optionalauthentication mode and a default boot mode.

Certain steps in the processes or process flows described in thisspecification naturally precede others for the invention to function asdescribed. However, the present system and methods are not limited tothe order of the steps described if such order or sequence does notalter the functionality of the above-described systems and methods. Thatis, it is recognized that some steps may be performed before, after, orin parallel (substantially simultaneously) with other steps. In someinstances, certain steps may be omitted or not performed withoutdeparting from the above-described systems and methods. Further, wordssuch as “thereafter”, “then”, “next”, “subsequently”, etc. are notintended to limit the order of the steps. These words are simply used toguide the reader through the description of the exemplary method.

Additionally, one of ordinary skill in writing boot programs and/orcircuit architecture is able to write computer code or identifyappropriate hardware and/or circuits to implement the disclosedinvention without difficulty based on the flow charts and associatedexamples in this specification. Therefore, disclosure of a particularset of program code instructions or detailed hardware devices is notconsidered necessary for an adequate understanding of how to make anduse the systems and methods. The inventive functionality of the claimedprocessor-enabled processes is explained in more detail in the abovedescription and in conjunction with the drawings, which may illustratevarious process flows.

In one or more exemplary aspects as indicated above, the functionsdescribed may be implemented in hardware, software, firmware, or anycombination thereof. If implemented in software, the functions may bestored as one or more instructions or code on a computer-readablemedium, such as a non-transitory processor-readable medium.Computer-readable media include data storage media.

A storage media may be any available media that may be accessed by acomputer or a processor. By way of example, and not limitation, suchcomputer-readable media may comprise RAM, ROM, EEPROM, Flash, CD-ROM orother optical disk storage, magnetic disk storage or other magneticstorage devices, or any other medium that may be used to carry or storedesired program code in the form of instructions or data structures andthat may be accessed by a computer. Disk and disc, as used herein,includes compact disc (“CD”), laser disc, optical disc, digitalversatile disc (“DVD”), floppy disk and blu-ray disc where disks usuallyreproduce data magnetically, while discs reproduce data optically withlasers. Combinations of the above should also be included within thescope of non-transitory computer-readable media.

Although selected aspects have been illustrated and described in detail,it will be understood that various substitutions and alterations may bemade herein without departing from the present systems and methods, asdefined by the following claims.

1-11. (canceled)
 12. A system for patching a sequence of instructionsstored in a read-only memory, the system comprising: a programmableread-only memory providing a set of addressable memory locations; aread-only memory having stored therein a sequence of instructions andpatch processing logic arranged to dynamically vector to identifiedlocations in the set of addressable memory locations in the programmableread-only memory and return to the sequence of instructions in theread-only memory; a random-access memory coupled to the programmableread-only memory and the read-only memory via a bus, the random-accessmemory arranged to store the sequence of instructions and the patchprocessing logic; a controller for loading the sequence of instructionsand the patch processing logic from the read-only memory to therandom-access memory; and a processor coupled to the random-accessmemory via the bus and configured to execute the sequence ofinstructions, wherein when a patch indicator is encountered in thesequence of instructions, the processor executes the patch processinglogic.
 13. The system of claim 12, wherein the patch indicator islocated at a place in the sequence of instructions where a requiredchange is probable after the sequence of instructions is embodied infirmware.
 14. The system of claim 12, wherein a patch instance is storedin the programmable read-only memory, the patch instance including emptycontent before a modification to the sequence of instructions in theread-only memory is identified.
 15. The system of claim 14, whereinafter a modification to the sequence of instructions in the read-onlymemory is identified, the patch instance includes at least a first wordwith an instruction type encoded therein and a second word with a patchaddress, the first word and the second word defining a patch.
 16. Thesystem of claim 15, wherein the first word further includes maskinformation.
 17. The system of claim 15, wherein the patch is defined inwords of N bits where N is an integer.
 18. The system of claim 15,wherein the patch includes replacement content only for the at least onepatch indicator.
 19. The system of claim 12, wherein the patchprocessing logic directs the processor to access an address, determineif a patch is available at the address, when a patch is not available atthe address, return to a next subsequent instruction in the sequence ofinstructions, otherwise, execute the instructions in the patch, andreturn to the next subsequent instruction in the sequence ofinstructions.
 20. The system of claim 19, further comprising: a set ofone time programmable fuses coupled to the processor for providing patchdata.
 21. A non-transitory processor-readable medium having storedthereon processor instructions that when executed direct the processorto perform functions, comprising: identifying when a patch indicator ispresent in a sequence of instructions; determining when a patch instanceis available at an address associated with the patch indicator, whereinwhen a patch instance is not available, loading a next subsequentinstruction from the sequence of instructions; otherwise, when a patchinstance is available, determining a patch type from information storedat the address associated with the patch indicator; and executing one ormore instructions in the patch instance.
 22. The non-transitoryprocessor-readable medium of claim 21, wherein the determining when apatch instance is available is responsive to information communicatedfrom a set of one-time programmable fuses.
 23. The non-transitoryprocessor-readable medium of claim 21, wherein the patch indicator islocated at a place in the sequence of instructions where a requiredchange is probable after the sequence of instructions is embodied infirmware.
 24. The non-transitory processor-readable medium of claim 21,wherein a patch instance is stored in a programmable read-only memory,the patch instance including empty content before a modification to thesequence of instructions in the read-only memory is identified.
 25. Thenon-transitory processor-readable medium of claim 21, wherein after amodification to the sequence of instructions in the read-only memory isidentified, the patch instance includes at least a first word with aninstruction type encoded therein and a second word with a patch address,the first word and the second word defining a patch.
 26. Thenon-transitory processor-readable medium of claim 25, wherein the firstword further includes mask information.
 27. The non-transitoryprocessor-readable medium of claim 25, wherein the patch is defined inwords of N bits where N is an integer.
 28. The non-transitoryprocessor-readable medium of claim 25, wherein the patch includesreplacement content only for the at least one patch indicator.
 29. Asystem for patching a sequence of instructions, the system comprising: ameans for providing a set of addressable memory locations, having storedtherein at least one patch instance; a means for storing a sequence ofinstructions and patch processing logic arranged such that when executedby a processor direct the processor to dynamically vector to identifiedlocations in the set of addressable memory locations and return to thesequence of instructions; a means for temporarily storing the sequenceof instructions and patch processing logic; a means for loading thesequence of instructions and the patch processing logic from the meansfor storing to the means for temporarily storing; and a means forexecuting the sequence of instructions from the means for temporarilystoring, wherein when a patch indicator is encountered in the sequenceof instructions, the means for executing executes the patch processinglogic.
 30. The system of claim 29, wherein the means for executing thesequence of instructions identifies when a patch indicator is present ina sequence of instructions; determines when a patch instance isavailable at an address associated with the patch indicator, whereinwhen a patch instance is not available, the means for executing thesequence of instructions loads a next subsequent instruction from thesequence of instructions; otherwise, when a patch instance is available,the means for executing the sequence of instructions determines a patchtype from information stored at the address associated with the patchindicator; and executes one or more instructions in the patch instance.